Repository navigation
fix(runtime): persist replay claims and preserve heartbeat cadence - #7969
Conversation
6805ccf to
9be693b
Compare
![aao-secretariat[bot]](https://avatars.githubusercontent.com/u/221690821?s=60&v=4){kind=small}
There was a problem hiding this comment.
Ladon verdict: Approve
Approve — clean, surgical runtime-reliability fix with no blocking findings.
Checked: the PR touches only server/** (compliance-db.ts, idempotency.ts, and two integration tests); no protocol surface (static/schemas/source/**, docs/reference/**, dist/**, task/compliance assets) is touched, so changeset / schema-drift / oneOf / immutability / 3.1.x-patch gates do not apply. No migrations under server/src/db/migrations/** are added.
- compliance-db.ts: schedule_next CTE now gates cadence advancement on
triggered_by($7); owner_test runs INSERTnext_compliance_check_at=NULLand skip the ON CONFLICT UPDATE, preserving requeued_at/streak/schedule. Parameter numbering consistent; CTE only reached for authoritative runs. NULL reads as due in getAgentsDueForCheck, matching tests. - idempotency.ts: lazy
{query}wrapper defers getPool() so production fails closed (throws until DB init) rather than downgrading to memory. Verified by the new cold-boot integration test across the claim/save/renew/release/fencing lifecycle.
Gate check: high_risk false, gated_paths false, no no-auto-approve team match, no prior decision. Reviewer reports no critical/high/medium findings. No decision-table trigger (rows 1–8) fires → row 9 approve.
There was a problem hiding this comment.
Ladon verdict: Approve
Approve — clean delta with no blocking findings.
This PR adds two server-side fixes, both covered by new integration tests:
compliance-db.ts: owner_test runs publish the verdict while leaving the independent heartbeat schedule and pending requeue untouched (#7680), via a CASE on INSERT and a WHERE guard on ON CONFLICT DO UPDATE; NULL next_compliance_check_at correctly reads as due.idempotency.ts: production now builds the fenced PG backend with a lazy getPool() resolver instead of caching a process-local memory backend before initializeDatabase(), failing closed until DB startup.
No published protocol surface (static/schemas/source/**, normative docs, release artifacts) touched, so no changeset required. No dist/ artifact mutation, no schema/docs drift, no oneOf regression. Server-only change.
Gate checks: no critical/high/medium findings (row 1 N/A); gated_paths false and review_decision APPROVED anyway (row 2 N/A); high_risk false (rows 3/5 N/A); no escalation-category mediums (row 4 N/A); prior decision was approve (row 6 N/A); no no-auto-approve team match (row 7 N/A); zero medium findings (row 8 N/A). Falls through to row 9 → approve.
The base branch was changed.
Production training-agent replay claims can otherwise select an in-memory backend before the database pool initializes, and owner compliance tests can re-arm scheduled heartbeat checks. Select the PostgreSQL replay backend in production before initialization and obtain the pool when a query runs; fail closed if it is unavailable. Publish owner-test verdicts while preserving heartbeat cadence, next scheduled checks, requeues and streaks. New owner-only records have no heartbeat schedule.
This is the existing #7969, refreshed onto main after #7968 merged. Its own four-file correction is preserved; current main supplies the inherited OAuth issuer fields and fixtures. It includes the scheduling fix from #7691, which remains a fallback until this replacement lands. No GCS reporting or 3.3 protocol changes are included.
Validation on
08dd3de94b17fa1bed131dd18559d5359e6f68f1with current-main SDK15 dependencies:Addresses #7899 and #7355 in part. A source merge does not establish fleet deployment, seller recovery or completion of the remaining operator verification. Those issue-level checks remain open.